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© Path measurement and analysis tool for evaluating the performance of software designs. 

© A software engineering tool is disclosed which enables the -efficiency and performance of a program design 
to be evaluated prior to the time the program is written into code. Every possible path that can be followed in the 
implementation of the program is identified, and its length is measured. From this information, reports are 
generated which point out the longest paths in the program and sources of potential performance problems. In 
addition, weights which identity relative complexities or performance timings can be assigned to individual 
modules in the program, and form the basis of other reports which indicate timing performance. The user is 
provided with the opportunity to alter the weights assigned to modules, and thereby determine the effect which 
different weights have on the overall performance of the program. 
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PATH MEASUREMENT AND ANALYSIS TOOL FOR EVALUATING THE PERFORMANCE OF SOFTWARE 

DESIGNS 

Background of the Invention 



The present invention generally relates to the development of software programs, and; is more 
s specifically directed to a novel programming tool which enables a software engineer to evaluate the 
expected performance of a program and isolate potential performance problems during an early stage of 
program development 

A typical life cycle in the development of a computer program includes the initial steps of analyzing the 
problem to be solved by the program and designing the overall structure of the program. After the general 

jo structure of the program has been designed, it is then constructed, or coded, after which it undergoes a 
period of testing and debugging.- Finally, after the program has been successfully, tested, it is released for 
general use. One difficulty associated with this traditional approach to the development of software is the 
fact that it does hot readily enable design defects to be recognized until substantially all of the work 
necessary to create the program has been completed. 'In other words, in the past it has always been 

75 necessary to construct the code for the program before it could be tested for the efficiency of its operation. 
Thus, once the code had been written and the program run during the testing phase, if unsatisfactory 
performance was detected it was necessary to return to the design phase to restructure the program, and 
then rewrite the code to implement the design changes. 

Often, the types of mistakes which are most expensive to correct are those which occur in the analysis 

20 and design phases of the software development cycle. In this regard, one of the factors which significantly 
influences the performance of a program is the lengths of the paths in the structure of the program that are 
followed to carry out a particular task. The length of the path is typically defined in terms of the number of 
transitions from module to module which occur as the program proceeds from an initial module to the final 
node in the path which represents completion of the task. As a path length becomes longer, it typically 

25 takes the program longer to execute the task, thereby reducing the efficiency of the program. Another factor 
which influences the performance of the program is the efficiency of a particular module which may be 
executed often by being called many times. 

In this regard, one popular methodology that is used in the development of software is known as 
Structured Design. Basically, this methodology involves breaking a task down into: smaller and smaller 

30 functional units. Through this approach, repeatable and more predictable results can be obtained in software 
development. However, since the structured design approach promotes functional decomposition and small 
module sizes, it can result in longer path lengths. As a result, the performance of the program could be less 
than optimal when this design methodology is employed. 

Unfortunately, since long paths are often difficult to manually identify, particularly in large and complex 

35 programs, the program must be coded and tested before long path lengths which affect its performance can 
be recognized. As a result, it can be appreciated that significant and expensive efforts may be required to 
redesign the program and then recode it once the performance limitations have been detected. Accordingly, 
it would be desirable to provide a software engineering tool which isolates possible performance problems 
early in the software development cycle, before coding, to thereby minimize the effort necessary to correct 

40 such problems. 

Brief Statement of the Invention 

In accordance with the present invention, a software engineering tool is provided which enables the 
expected efficiency and performance of a program design to be evaluated prior to coding. It is particularly 
designed to work with the results of the Structured Design approach to software development. Basically, 
conventional software tools that are used in the implementation of the Structured Design approach provide a 
so database which includes a specification for each module (functional element) in the design, as well as the 
overall relationship of the modules to one another. Utilizing this information, the performance evaluation tool 
of the present invention determines every possible path that can be followed in the implementation of the 
program. From these determinations, reports are generated which identify the longest paths in the program, 
and hence the sources of potential "bottlenecks" in the performance of the program. 
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In addition, the relative time that would be required to follow each path can be determined on the basis 

wn.ch are called most often in the implementation of the program can be identified and called to the 
program developer's attention as program elements which may need to ta mStdoX revSled for 
s poss.ble optimization. As a further feature, the performance evaluation tool «^S^£T££ 
various hypothetical situations and evaluate their effect on the efficiency of the proglam 

By means of the design evaluation tool, the present invention enables the program developer to identifv 
and correct some types of design deficiencies before any coding of the program eZ tate pfcce tSebv 

» C " 9 ^ C ° St ^ M reQUired 10 Pr ° dUCe 3 which ope^s w^oS 

Further features of the present invention and the advantages offered thereby are exDlained in nr«w 
deta.1 hereinafter with reference to various examp.es illustrated* the acc^!^^^ 



Brief Description of the Drawings 



20 



25 



30 



Figure 1 is a block diagram flow chart of the prior art approach to the development of software- 

p*«^i"p^5K f,ow chart depictin9 8 software devetopment m cycte wwch ^ ** 

Figure 3 is a general block diagram depicting the functional operation of the present invention- 

m^^SEZX s,ructure chart ,hat can be produced *• •-—W 

Figure 5 is an example of a spreadsheet that can be generated by the design evaluation tool- 

kZI Vl\ 9 StfU ? re Ch3rt dep, ' C,inS the 0vera " operation of «» P^ent invention; and 
Figure 7 is a more specific flow chart illustrating the analysis of the inforrrtation in the Stactun*' 
Design database to create an internal path structure file 'nrormation in the Structured 

Description of the illustrated Embodiments 

hri J^^*^ that ha$ bee " conventional, y em P'oyed m the development of software will first be 
briefly described with reference to Figure 1. In a structured systems design approach, the first step "nvSS 
a Structured Analysis 10 of the basic objectives of the software. GeneJy. £ pSm^TJSSZ 
1 1 t P h 5 requiremen,s for the P<°9™- Once these requirement have been WentiS a 

Structured Design approach 12 is employed to define the tasks to be carried out by the software When^ 
these teste have been designed with sufficient particularity, actual codin g 0 f the program take! Sace at 
step 14. After the coding phase, the program undergoes a testing and evaluation P has7l6 
«J£p* t«f ° f h th ! teStin9 Ph3Se ' ' imitati0nS the P erforman <* of the program will be recognized For 
sSl h! , ^ COmP ' eted in 3 SpeCified Peri0d of time wi » * identified. At this pom the 

software development process returns to the design phase 12. where the design is revised to reduce or 
e .m,nate the performance bottlenecks. As a resuit of these design changes. additional coding 4 nS take 
place, which is followed up by further testing and equation steps 16. The closed loop process ol 
designing, coding, and testing might go through several iterations before the program final^ ope S at a 

In accordance w,th the present invention, much of the time that is spent during the testing redesian and 
recod.ng phases of the software devetopment cycle can be significantly reduc e rb7e^. u S £ 
efficiency of the design prior to the time that coding of the program takes place. Referring to S 2 a 
software development cycle that employs the techniques of the present invention begins with an ana. ys is of 
oh Jr?T? ^ K P t° rmed bV Pr09ram ' preferab, V usi "9 *• Structured jL^£££*£ 
Th^ 1 d ? Si9n Ph3Se 12 f ° r the Pr09ram ' a 9 ai " P^ferably using a Soured Design 
technique. The software tools that are employed in accordance with this technique generate a database 

Z ? ?" "? bS US6d t0 6Va,Uate ,hS ° Vera " 6ffiCienc y of d * si 9" >" accordance wiS 
oL^rlr , ° eSi9ri " 3 We " kn0Wn meth0d «* is conventionally employed by 

software engineers, and therefore will not be described herein. For a detailed description of this design 
approach reference ,s made to Tim Practical Guide to Structured Systems Design byTi» ftolSS 
published by Yourdon Press, New York, 1980. 9 

Using the information provided as' a result of the Structured Design, an evaluation 20 of the design 
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takes place immediately following the completion of the design step 12, and prior to the coding phase 14. 
As a result of this evaluation, various inefficiencies in the design can be detected and called to the software 
engineer's attention. For example, as discussed previously, one factor which significantly contributes to the 
efficiency of a program is the lengths of the paths that must be followed to execute a particular task. The 
5 evaluation step 20 can determine the lengths of the paths that must be followed during the operation of the 
program under development In addition, the evaluation phase 20 can operate to identify modules 
(functional elements) in the program which are utilized most frequently and call these modules to the 
designer's attention as likely candidates for optimization, as well as provide other information which helps to 
isolate possible performance limitations. 
io With the information provided from the design evaluation step 20, the software engineer can redesign 
the program to reduce or eliminate the possible inefficiencies. After the program has been redesigned, it 
can again be evaluated in accordance with the present invention, and further refined as necessary. Once 
the design evaluation step 20 provides an indication that the program structure meets a satisfactory 
performance level, the design can be presented to a programmer for the conventional steps of coding 14 

75 and testing 16. Since the design evaluation helps to identify and reduce design inefficiencies prior to 
coding, the testing phase 16 is more likely to be concentrated on specific coding errors and the debugging 
of these errors. Coding errors are much easier and less expensive to correct than design mistakes, and 
hence the overall effort and time required to put the program in form for final release 18 could be 
significantly reduced, particularly for large and highly complex programs. 

20 The general architecture of a system for performing the design evaluation phase 20 is illustrated in 
block diagram form in Figure 3. Referring thereto, the tools which are employed to carry out the Structured 
Design approach to software engineering provide a database 22 which contains information describing the 
overall structure of the program as well as the functionality of its individual modules. The overall structure of 
the program is typically represented by means of a structure chart, an example of which is shown in Figure 

25 4. The particular example represented in Figure 4 is for a relatively simple program, to facilitate an 
understanding of the invention and its application. It will be appreciated, however, that the present invention 
is particularly useful in connection with large and highly complex program designs, whose structure charts 
may typically be spread over a number of sheets and are therefore difficult to manually comprehend. 

In the structure chart, each of the blocks which is labeled with a letter represents a module in the 

30 program. The lines interconnecting the modules identify the hierarchical relationships of the modules to one 
another, and serve to define the paths which are followed in the operation of the program to perform 
specific tasks. In addition to information describing the structure chart, the database 22 (shown in FIG. 3) 
also contains a specification for each individual module. This specification basically describes the inputs of 
a module, the function performed within the module, and the outputs of the module. 

35 The information contained within the database 22 is accessed by a design evaluation tool 24 which 
operates in accordance with the present invention. In one mode of operation, the evaluation tool 24 
determines the length of every possible path that can be followed during the running of the program. 
Basically, a path length is defined in terms of the number of transitions from an initial module to the final 
node in the path. Referring to the structure chart shown in Figure 4, the path from the initial module A to the 

40 terminal module M contains two transitions, from module A to C and then from module C to M. Thus, this 
path has a length of 2. 

In operation, the user specifies a particular module of interest, which can be the beginning module in a 
task execution path. Each possible path that can be followed from this initial module is then determined, 
and its length is measured. After all possible paths have been evaluated, the tool 24 generates reports 26 
45 on a printer or a video display that are indicative of such evaluation. One such report can list all possible 
paths from the specified module, such as the root module A for example, and their corresponding lengths. 
For the program of Figure 4, such a report would appear as follows in Table 1 : 
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Table 1 
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ALL PATHS 


rain 


Path 




Length 


A/B/E/G 


3 


A/B/E/H/l 


4 


A/B/E/H/l/L 


5 


A/B/E/H/K/R 


5 


A/B/F 


2 


A/C/M 


2 


a/c/n/o/k/r' 


5 


A/C/N/P 


3 


A/C/N/Q 


3 


A A D/K/R 


1 2 


A/W/T/U/T/... 
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Table 2 



EXCESSIVE PATHS 


Path 


Path 




Length 


A/B/E/H/J/L 


5 


A/B/E/H/K/R 


5 


A/C/N/O/K/R 


5 



A third type of report can identify portions of the design and program that the engineer may wish to 
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optimize. In the generation of this report, the user specifies a number which indicates the unique number of 
calls to any module or sub-path. The purpose of this number is to identify the modules and sub-paths that 
are called most frequently by other modules. For example, if the user specifies the number 3, the design 
evaluation tool 24 generates a report identifying all sub-paths that have at least 3 unique calling modules. 
For the example shown in* Figure 4, such a report would appear as shown in the following Table 3: 

Table 3 



OPTIMIZATION 


Path 


# Calls 


Calling 
Modules 


K/R 


3 


H.O.D 



In addition to reports which are based upon the lengths of paths in the structured design, the evaluation 
tool 24 can also provide reports which are based upon the anticipated time that would be required to 
complete certain tasks. In this mode of operation, the' user assigns a relative weight;to .each module in the 
program structure. The weight assigned to a module is a number which represents, for efxample, the relative 
complexity of the module or the anticipated performance time of the module. These weights can be entered 
during the design phase 1 2 of the program and stored in the Structured Design database 22 as part of the 
module specificaton. Alternatively, the weights can be entered by the user during the design evaluation 
phase 20 and rtorod in a worksheet file 28, for example. 

The too* 24 win read the weights from the worksheet file and update the module specifications in the 
design database 22 automatically. A weight of 1 , for example, can be associated with a relatively simple 
module, and each other module can be assigned, a weight value which indicates the complexity of that 
module relative to that of the simple module. Thus, a module with a weight of 3 would be expected to take 
3 times longer to execute man the simple module having a weight of 1. Iff the user fails to specify a weight 
for a given module, tne tool 24 can assign a default weight (for example, a weight of 1) to such module. 

In this mode of operation, a timing report can be generated which identifies each path with its timing 
weight. The timing weight for a path would be the sum of the weights for each module in the path. As a 
subset ot this report, tne user can request that only those paths having a timing weight greater than a 
specified threshold level be identified. 

As an alternative to designating specific weights for each module, the software engineer can identity 
each module as being of a particular type and store this identification as part of the module specification in 
the structured design database 22. The user can also provide a file which contains a list of module types 
and a performance weight for each type. The evaluation tool 24 can then refer to this file and assign the 
appropriate performance weight to a module based upon its type. 

In addition to weighting each of the individual modules, a probability can also be assigned to each 
invocation path that is conditionally activated (not always called). In the example illustrated in Figure 4. the 
paths from the module n to each of the modules o, p and q are conditional. This status is indicated by the 
diamond symbol at the output of the module n. For each of these conditional paths, a probability of its 
likelihood of being called can be assigned by the user. When generating a report on the paths that are most 
commonly called, the weighting information can be factored into the expected performance of the program. 

A particularly useful report that can be generated with the design evaluation tool of the present 
invention is a performance report which identifies paths that should be of particular concern to the software 
engineer from the standpoint of possible performance problems. This type of report takes into account both 
path lengths and path weights and is comprised of three sections as shown in Table 4 below: 
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Table 4 , 



10 



75 



20 



25 



u 


ESCENDING PATH LENGTHS 


Path 


Length 


Loops 


Conds 


, A/B/E/H/J/L 

A/B/E/H/K/R 

M/O/lN/U/K/n 
A/R/C/uyf 

>VD/t/n/l 


5 


2 


2 
1 
1 
1 


5 


2 


5 


1 


4 


2 


DE 


:SCENDING PATH WEIGHTS 




Path , 


Weight 


Loops 


Conds 


A/B/E/H/K/R 
A/B/E/H/l 
A/B/E/H/J/L 
A/C/N/O/K/R 


11.00 


2 
2 
2 
1 


1 
1 
2 
2 


8.50 


6.15 


5.85 


DESCEND 


ING PATH LENGTHS & WEIGH 


TS 


Path 


Length 


Weight 


Loops 


Conds 


A/B/E/H/K/R 
A/B/E/H/J/L 
A/B/E/H/l 
A/C/N/O/J/R 


5 
5 
4 

6 


11.00 ; 

6.15 
8.50 
5.S5 


2 

, 2 
. 2 
1 


1 

2 
1 
2 
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modules B and C are listed. Again, the weight for each of these modules is shown to the immediate right of 
the module identification. Below the weight for each of these two modules are listed other modules that can 
be called from these modules, along with their assigned weights. For each module which is the terminal 
module in a path, the summed weight for the path to that module is also listed. Thus, the total weights of 
the paths A/C/M and A/B/F (4.8 and 325. respectively) are shown to the extreme right in the example of 
Figure 5. 

An advantage associated with the presentation of this information in a spreadsheet is that it enables the 
user to create hypothetical situations from which he can assess the overall performance of the program. 
Specifically, the user can alter the weights of individual modules within the spreadsheet; when the 
spreadsheet is recalculated, the user is provided with updated information that shows how the new module 
weight affects the overall performance of the program. In this regard, the tool 24 can generate a report 
which lists the original weight of a module, the new weight assigned by the user, and a "delta" or difference 
between the two weights. This delta can be expressed as a percentage of the original weight. The report 
can also identify the percentage difference which the weight change will have on the performance timing of 
each path in which the changed module is located. From this information, the user can determine whether 
optimization of a particular module, for example to reduce its complexity, is a worthwhile effort. If desired, 
the user can instruct the evaluation tool 24 to update the software design data base 22 with the revised 
weights entered into the spreadsheet 30. 

A general structure chart for the overall operation of the design evaluation tool 24 is illustrated in Rgure 
6. The tool begins operation in a main routine 32 which handles initialization and various other housekeep- 
ing chores and controls the overall flow of the program. Once these general operations have been carried 
out, the program branches to a routine 34 for building an internal path structure file. In this process, the 
structured design database 22 is analyzed within another routine 36 and a file is built which describes all of 
the paths, their lengths and weights, and associated loop and condition information. After the internal file 
has been built, the program branches to a routine 38 to generate reports. As part of this function, the 
program reads the data stored in the internal file and formats this data to produce the appropriate reports 
by means of a routine 39. / 

Thereafter, the design evaluation program can branch to the spreadsheet interface routine 40. Within 
this routine, the appropriate data from the internal file is again read (subroutine 40A) and a worksheet file is 
built (subroutine 40B). A suitable spreadsheet application program is then called (subroutine 40C) and the 
spreadsheet is displayed. If the user modifies any of the weight values for the module, the updated 
information is read (subroutine 40D) and used to update the database 22 (subroutine 40E). The updated 
data is also used to generate the delta reports (subroutine 40F). 

A more specific flow chart which illustrates the operation of the database analysis routine 36 is shown in 
Rgure 7. Basically, the evaluation of the design being tested proceeds as a series of nested loops in which 
each possible path in the structure of the design is identified and its length is measured. 

At the outset, the tool begins at a starting module selected by the user. If the user does not select a 
starting module, the tool starts with the root module (module A in the example of Rgure 4). The weight of 
the starting module is stored as indicated by a block 101 in FIG. 7. The starting module defines a top or 
first module level. 

A variable "i" is used to identify any second level modules which are called from the starting module. 
This variable is initially set equal to 1, as indicated by a block 103. A level counter "c" is used to keep track 
of how many levels there are between the starting module and a terminal module, and this variable is also 
initially set equal to 1„as indicated by a block 105. 

By referring to the module specification stored in the data base 22, the tool 24 finds and stores the 
weight of the i-th second level module which is called from the root module, as indicated by a block 107. 
The tool also finds whether any third level modules are called from the i-th second level module, as 
indicated by a decision block 109. If so, a variable Y is used to identify such third level modules. This 
variable is initially set equal to 1, as indicated by a block 111, and the level counter "c" is set equal to 2 as 
indicated by a block 113 to show that there are two levels between the starting module and the j-th third 
level module. Then the weight of the j-th third level module is stored as indicated by a block 115. 

Similarly, the tool finds whether any fourth level modules are called from the j-th third level module, as 
indicated by a decision block 1 17. A variable n k" is used to identity such fourth level modules and is initially 
set equal to 1, as indicated by a block 119. and the level counter "c* is set equal to 3 as indicated by a 
block 121. Then the weight of the k-th fourth level module is stored as indicated by a block 123. 

The process continues with any fifth level modules which are called from the k-th fourth level module, 
as indicated by a decision block 125, and so forth. 

Eventually a terminal module (a module which calls no lower-level modules) is reached. When this 
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JS^^t^^SS^ *" h T T foUS ^ «*«~ «• a" other 
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modules, the tool determines whetLfanv cZ « . , * S,m " arly ' if there are no m ™ level 
indicated by a deos,on Zl ^Tn s^i isTcr^^ " Ca " ed * *• s,artin 9 «»**. as 

the block ,05. When no nSe modu es a e'eft hZ21 "fl* 3 b ' 0Ck 143 «« the ** returns to 

From the forego.ng. « w,n S^SSSj^ t S^ S .T* ,ne 36 e " dS aS indicated * a block 145. 
a too. to eva^me'emoency 6 T^S^^^J^ T ** ^ ^ en9ineer with 
developmen, He cycle of the program S Z^l! T ^ performance drawbacks, early in the 
such an early stage, the need Z iteoflZ ^ , e " 9ineer witn this * pe of information at 

subsequent.; ^^Tt^^Si^^^ " *" lnm *" " eed t0 be 
different penormarj wagnts forl^rnSe an rrl c ' by enabl,n 9 the desi 9"er to experiment with 
performance, **gns cao'be ** **« ° f ,h6Se different " ei 9"* on total 

modules at each .eve., and man ^ZZZSTZJ^ ^ *** ^ ^ " UmberS 0f leve,s ' 
such systems is so com P , ex as t d eTy a n ?£ZZTJTi ^ *"* The Structure ° f ^ 

makes .t possibte for the engineer ^ equate SUC h I w h ' ^ The Pr6Sent inventio " 

all before any coding has taken p.ace 9 ' P ° tent,a ' tr0Uble s P° te 3011 "riBct them. 

he -7.0^^ °^ -ire,y new programs. ,t can also 

« wi« be appreciated by Lse of ^ " the art Zt^ *'* ^ l ° 
* in other ways and embodied in other specific 1 1? I !, present ,nvention be implemented 
characteristics hereof. The preset ^ dTsclosed emhoZ J*^" 9 U ° m the spirit 0f es5en «a. 

illustrative and not restrictive rS scooT^T I "* considere d in all respects to be 

the foregoing description and ^ o h 7Z s \^ '^'Z-' by aPPe " ded C,aims ^ than 

are intended to be embraced the ein ™ ^ meani " 9 and ran 9 e of e ^nts thereof 
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producing a report which lists the stored identification of at least some of said determined paths and the 
measured length for each listed path. 

2. The method of claim 1 wherein said report lists every possible path in the execution of said program 
and the measured length for each such path. 
5 3. The method of claim 1 further including the step of selecting a threshold path length, and wherein 
said report lists those determined paths having a measured length which is greater than said threshold 
length. 

4'; The method of claim 1 further including the steps of selecting a threshold call number, determining 
each module which can be called by a number of other modules equal to or greater than said threshold call 
io number in the execution of tasks by said program, and producing an optimization report which identifies at 
least said determined modules. 

5. The method of claim 4 wherein said optimization report also identifies the modules which can call 
each determined module. 

6. The method of claim 4 wherein said optimization report also identifies all modules in a path that are 
75 subsequent to each determined module. 1 

7. The method of claim 4 wherein said optimization report also lists the number of unique calls that can 
be made to each determined module. 

8. The method of claim 1 further including the steps of assigning a weighting factor to each module in 
•the program, summing the weighting factors for all modules in at least some of the determined paths, and 

20 producing a timing report which identifies the determined paths and the summed weights for each. 

9. The method of claim 8 wherein said timing report identifies all determined paths and the summed 
weight for each. 

10. The method of claim 8 further including the step of selecting a threshold weight and said timing 
report identifies all paths whose summed weight exceeds said threshold weight 

25 11. The method of claim 8 wherein the step of assigning a weighting factor to each module includes 
identifying each module as being of a particular type, establishing a table which associates a weighting 
factor with each type of module, and accessing said table to determine the weighting factor for a particular 
module on the basis of its type. 

12. The method of claim 8 wherein the step of assigning a weighting factor to each - module includes 
30 assigning a default weight value to each module and modifying the assigned weight value, for a particular 

module in response to a manually entered weight value for that module. 

13. A method for evaluating the design of a program during development of the program by means of a 
process in which a database that identifies each functional module in the program and the hierarchical 
relationships of the modules to one another is created and stored, comprising the steps of: 

as specifying a module in the program which forms a starting point for one or more tasks to be executed by 
the program; 

accessing said database and determining possible paths from the specified module to other modules in 
said hierarchical relationship that can be followed by said program in the execution of a task, and storing an 
identification of the determined paths in a memory; 
40 assigning a weight factor to each module in the determined paths; 

summing the weight factors for all modules in at least some of the determined paths; and 
producing a report which identifies the determined paths and the summed weight for each. 

14. The method of claim 13 wherein said timing report identifies all possible paths that can be followed 
in the execution of the program and the summed weight for each. 

45 15. The method of claim 13 further including the step of selecting a threshold weight and said timing 
report identifies all paths whose summed weight exceeds said threshold weight 

16. The method of claim 13 wherein the step of assigning a weighting factor to each module includes 
identifying each module as being of a particular type, establishing a table which associates a weighting 
factor with each type of module, and accessing said table to determine the weighting factor for a particular 

so module on the basis of Hs type. 

17. The method of claim 13 wherein the step of assigning a weighting factor to each module includes 
assigning a default weight value to each module and modifying the assigned weight value for a particular 
"module in response to a manually entered weight value for that module. 

18. The method of claim 13 wherein said report comprises a spreadsheet which enables assigned 
55 weight factors to be modified and provides an indication of the effect which a modified weight factor has on 

the summed weight of the determined paths. 

19. A tool for evaluating the design of a program, comprising: 

means for accessing a database which identifies each functional module in a program and the hierarchical 
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20 



25 



relationships of the modules to one another- 

20 A tool for evaluating the design of a program, comprising: 
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@ A software engineering tool is disclosed which 
enables the efficiency and performance of a program 
design to be evaluated prior to the time the program 
is written into code. Every possible path that can be 
followed in the implementation of the program is 
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timings can be assigned ^individual modules in the 
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indicate timing performance. The user is provided 
with the opportunity to alter the weights assigned to 
modules, and thereby determine the effect which 
different weights have on the overall performance of 
the program. 
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